之前写过 Java &Go高性能队列之LinkedBlockingQueue性能测试之后，就一直准备这这篇文章，作为准备内容的过程中也写过一些Disruptor高性能消息队列的应用文章：高性能队列Disruptor在测试中应用和千万级日志回放引擎设计稿。

Disruptor以高性能出名，下面我来测试一下三种场景下性能表现。

有一些基本的设定和用词规范，大家可以翻看Java&Go高性能队列之LinkedBlockingQueue性能测试。

总体来说，com. LMAX .disruptor.dsl.Disruptor消费性能是非常厉害的，几乎是测不到顶。但是在生产方面，性能会随着Event的增加会下降很多 还是在50万QPS级别上，满足现在 压测 需求，唯一需要避免的就是队列较长时性能不稳定。总结起来几点比较通用的参考：

这里再多唠叨两句。

这里性能只记录每毫秒处理消息（对象）个数作为评价性能的唯一标准。这里我采用的是com.lmax.disruptor.dsl.ProducerType#MULTI消费模式，注册消费者用的是com.lmax.disruptor.dsl.Disruptor#handleEventsWithWorkerPool方法。

这里我用了三种org. apache .http.clienthods.HttpGet，创建方法均使用原生API，为了区分大小的区别，我会响应增加一些 header 和URL长度。

小对象：

中对象：

大对象：

测试过程中超大com.lmax.disruptor.AbstractSequencer#bufferSize会导致com.lmax.disruptor.dsl.Disruptor耗时非常长，自测1024 * 1024 再高就感觉很吃力了，所以没测试超过1百万的消息队列长度。由于并没有设定com.lmax.disruptor.AbstractSequencer#bufferSize的测试场景，所以本次测试总是用这个设置。

测试结果规律倒是挺明显的：

对于Disruptor框架来讲，单独的消费者用例比较难构建，我用了一个取巧的办法，会对性能测试结果有一些影响，这里可以通过后来分享 测试用例 的时候会详细说说。不过对于Disruptor逆天的消费能力，这点误差可以忽略。

测试结论也挺明显的，基本与java.util.concurrent.LinkedBlockingQueue一致。

PS：关于Disruptor消费能力，我测试了一个1百万大对象消息，1000线程的消费者用例，QPS=3412/ms，这个跟我后面基于Disruptor设计的新性能测试模型有关系，表明消费者 线程 数即使增加到1000，Disruptor依然保持了非常高的性能。

这里的 线程数 指的是生产者或者消费者的数量，总体线程数是此数值的2倍。

次轮整个测试过程都是几乎崩溃的，因为同样的用例执行起来误差太大了，最大的能有接近2倍的差距。以下结论仅供参考：

其中当线程数超过10的时候，出现了非常明显的性能下滑，这个可以通过上面两组数据得出原因，Disruptor消费太快了，是生产者的数倍之多。最后测试出来的结果其实就是生产者的速率。当线程数比较少的时候，Disruptor总是有消息堆积的，所以生产者速率不会成为瓶颈，这个也跟用例设计有关系。

请翻阅上期的测试文章内容Java&Go高性能队列之LinkedBlockingQueue性能测试。

测试用例使用 Groovy 语言编写，自从我自定义了异步关键字fun和复习了闭包的语法之后，感觉就像开了光一样，有点迷上了各类 多线程 的语法实现。本期我又额外使用了自定义统计时间的关键字time以及利用闭包实现自定义等待方法，其他内容均与上期文章相同。

Disruptor有个先天的优势，就是必需得设置ringBufferSize，相当于提前分配内存了。这点是我之前没想到的，当我回去复测LinkedBlockingQueue的时候发现并没有明显的性能差异，对于测试结果影响可忽略。

PS：这里用到了一些sleep()，会导致一些误差，这个以我能力暂无法避免，经过测试对结论影响不大，对数据影响有限。